협업 초보 팀의 Git 협업: 이론과 현실의 차이

벌써 3학년 1학기가 끝났다

이번 학기는 정말 빠르게 지나간 느낌이다. 이번 학기 동안 여러 큼직한 이벤트들이 있었지만, 무엇보다 가장 큰 이벤트는 학기 프로젝트였던 것 같다.

프로젝트 개요

"객체지향 프로그래밍" 이번 학기 프로젝트를 진행한 과목이다. 프로젝트 내용은 C++를 활용하여 자율 주제의 프로그램을 개발하는 것이었는데, 핵심은 팀 단위로 프로젝트를 진행하는 것이었다.

사실 누군가와 함께 프로그램 개발을 진행한다는 게 처음이라 어떤 방식으로 진행해야 할지 감이 잘 잡히지 않았다.

Git 협업 방식 연구

일단 평소에 Git, GitHub를 계속 사용해왔기에, Git과 GitHub를 이용한 협업 방식에 대해 구글링을 꽤 오래 했다.

그렇게 해서 두 가지 협업 전략 "Git Flow", **"GitHub Flow"**에 대해 어느 정도 알게 되었다.

Git Flow vs GitHub Flow 비교

실제 선택한 협업 방식

결론부터 이야기하자면 우리 팀이 사용한 방식은 이 두 방식 모두 아니다.

초기 계획: GitHub Flow 응용

개발 초기에는 "GitHub Flow"의 기능 단위 브랜치를 활용한 협업 방식을 응용하여 개인 브랜치에서 기능별 브랜치를 생성하여 작업하는 방식으로 진행하였다.

계획은 위 방식대로 브랜치를 만들어 작업한 후, PR을 올려 병합하는 것이었다.

하지만, 팀원들은 Git과 GitHub 둘 다 처음 사용해보는 것이었고, 나조차도 Git, GitHub를 개인 용도로만 사용해보았기 때문에 개인 브랜치를 생성하고, 기능 단위로 브랜치를 생성하여 개발 후 병합하는 과정이 너무 복잡하고 어렵게 느껴졌다.

특히 개인이 작업한 내용을 main 브랜치에 merge하는 과정에서 코드 충돌이 발생했을 경우 코드 충돌을 해결하지 못하고 결국 충돌하는 커밋 중 하나를 날리는 경우가 몇 번 발생했다.

최종 선택: 단순한 개인 브랜치 방식

결국 복잡한 협업 방식은 제쳐두고 우리 팀은 main 브랜치와 개인용 브랜치 3개만을 이용하여 협업하게 되었다.

PR을 기반으로 리뷰하는 것도 진행하지 않고 개발 내용을 단톡방에 공유하는 방식으로 진행했다.

우리 팀의 협업 워크플로우

1. main -> 개인 브랜치 생성
2. 개인 브랜치에서 작업
3. main 브랜치에 merge
4. 단톡방에 작업 내용 공유

하지만 위 방식 또한 문제가 있었다. merge하는 과정에서 코드 충돌이 발생하는 건 여전했다는 것.

물론 사소한 코드 충돌은 해결할 수 있었지만, 양쪽에서 AI를 활용한 대량의 코드 수정, 추가가 발생했을 경우엔... 충돌을 해결하는 것을 포기한 경우도 있었다.

그래서 선택한 방식은 팀원 중 누군가가 작업을 진행 중일 때 나머지 팀원은 충돌이 일어날 만한 다른 작업은 진행하지 않는 것이었다.

이 방식을 선택하여 진행한 이후 프로젝트는 코드를 짜는 것에서 오는 어려움을 제외한 다른 어려움은 없이 꽤 순탄하게 진행되었다.

회고 및 개선점

첫 협업이었기에 이 정도로 만족은 한다.

하지만, 추후 또 누군가와 협업을 하게 된다면 좀 더 효율적인 협업 전략과 규칙을 정립한 후 개발을 진행해야겠다는 생각이 들었다.

미리 정해야 할 규칙들

협업을 진행해보니 다음 규칙들을 미리 정해놔야 할 것 같다:

• 브랜치 전략
• 브랜치 네이밍
• 커밋 메시지 규칙
• 커밋 단위
• PR 규칙
• merge 전략

처음부터 잘 하는 사람이 어디에 있겠는가.

다음 협업 땐 좀 더 나은 모습으로 진행할 수 있을 것이라 믿는다.